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ABSTRACT 

The Space Flight Operations Center 
inaugurated the concept of a central data 
repository for spacecraft data and the 
distribution of computing power to the end 
users for that data's analysis at the Jet 
Propulsion Laboratory. The Advanced 
Multimission Operations System is 
continuing the evolution of this concept as 
new technologies emerge. Constant 
improvements in data management tools, 
data visualization, and hardware lead to 
ever expanding ideas for improving the 
analysis of spacecraft health in an era of 
budget constrained mission operations 
systems. The foundation of this evolution, its 
history, and its current plans will be 
discussed. 
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1. INTRODUCTION 

While the goal of space operations is the 
collection and analysis of scientific data, 
there is a vast infrastructure required to 
support that collection. An important part of 
that infrastructure is the analysis of 
spacecraft health. Immense volumes of data 
are tracked by a budget constrained team. 
An analogous situation is the classic comedy 
sketch where Hubby goes to get his bowling 
ball out of the hall closet on bowling night. 
He opens the door and an avalanche falls on 
him. The sketch ends by him triumphantly 
holding up his bowling ball amidst the 
rubble. Spacecraft analysts have faced their 
own avalanche by asking for data from their 
telemetry system. A request for data usually 
means running a magnetic tape through the 
telemetry system and handing the results to 
the requestor who dives in and hopes to 
emerge triumphantly with the few 
measurements desired in the first place. 


2. HISTORY 

The Jet Propulsion Laboratory (JPL) has had 
several generations of data systems in its 
support of spaceflight. In the late '60s, IBM 
7044s and IBM 7094s comprised JPL's 
spaceflight data system. About twenty years 
ago there was a new generation of data 
system introduced that started a roller 
coaster of capability for users of these 
systems. 

2.1 Twenty Years Ago 

Twenty years ago a new generation of data 
system was being introduce into JPL's 
repertoire for spaceflight support. It was 
comprised of a block redundant IBM 360/75 
running a batch orientated operating system 
modified by the Johnson Spaceflight Center to 
support real time processing. 

While the real time aspects of this data 
system provided a means of changing which 
Deep Space Station the data was processed 
from, there was little to be done to affect the 
direct processing of the data. Also, while 
there was a set of displays to choose from, they 
were hardcoded and required a software 
delivery for any changes to be incorporated. 
The only control the users had was which 
displays were routed to which printers or 
Digital Television (DTV) Channels (Fig. 1). 

There was little in the way of disk storage 
and the data was written off to magnetic tape 
to be made into products for the science 
community. The archive for the 
engineering community were the printouts 
and hardcopies of DTV screens that were 
collected and stored. (Ref. 1) Data reduction 
of these printouts was comprised of an 
engineer going through the printouts and 
either recording or plotting desired values in 
a journal. 
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As time went on, the Graphics Display 
System (GDS) was envisioned and 
implemented. The GDS allowed individual 
users to create their own displays with a 
simple language. They could not control 
what data flowed through their displays but 
they could tailor their displays for their own 
needs. A macro feature was also 
incorporated into the GDS, called super 
formats, in which once a set of templates were 
defined for the display of data, all the user 
had to do was specify the data and template 
and not have to get involved with the details. 

2.2 Mini-Computers - The Next Generation 

In the mid-70s, the arrival of the mini- 
computer heralded a change to spaceflight 
support at JPL. It was believed they were so 
inexpensive that multi-mission systems did 
not have to be developed anymore, every 
project could have their own dedicated sets of 
mini-computers. 

It was decided that the Command Subsystem 
would be moved to mini-computers. About the 
same time, Voyager decided that they would 
use their telemetry system that was 
supporting spacecraft system test for flight 
support. The result of this move caused the 
loss of users being able to create their own 
displays in realtime. This was due too the 
fact that displays were already hardcoded in 
the Telemetry System and it was decided to 
have hardcoded displays in the Command 
System to reduce cost. 

While realtime spacecraft support was 
regressing, non-realtime was gaining. As 
flight support was moving off of the IBM 
360/75s, they started to be used to make the 
archive data products. This was the 
beginning of what has become the Data 
Records System (DRS). A capability of DRS 
was to allow a request for a set of data and 
have that data either printed in a tabular 
form or plotted. The drawbacks of this 
system were that it was seven days before the 
data was available in the DRS, the data 
usually expired less than thirty days after its 
receipt on the ground, the request had to be 
submitted to an operator, and it could take 
several days to process the request. 


2.3 Data Staging 

In the early ‘80s, it was perceived that if data 
could be kept on disk until processing of it 
was complete, operations costs could be 
reduced. Merging files on disk is less labor 
intensive than hanging magnetic tapes and 
merging data from magnetic tapes to 
magnetic tape. Data on disk could be merged 
from multiple files or data merged into an 
indexed sequential access method file. 

The Multi-Mission Telemetry 
Transportation Demonstration (MTTD) was 
a prototyping attempt to design a multi- 
mission telemetry system that would provide 
enough disk space to allow data to be kept on 
disk until the final data products could be 
generated. Unfortunately, this effort never 
came to fruition. 

After the MTTD had been canceled, the three 
spacecraft mission Active Magnetosphere 
Particle Tracer Explorer was approved. For 
the United States spacecraft it was decided 
that there would be enough disk space to keep 
data online until the Master Data Record 
(MDR) could be generated. The result was 
that staffing for the creation of MDRs was 
held to one person. This was in contrast to the 
estimate of three people during the initial cost 
estimates for the project. The importance of 
data staging was realized as a major cost 
savings when the operational aspects were 
included in the cost of a project. 

For launch, Voyager had used a Univac 1530 
to do frame synchronization and error 
correction. During one of its encounters, the 
spacecraft data format was changed and 
could not be accommodated by the Univac 
1530 any longer. Also about this time, JPL 
was to provide a telemetry front end for 
Ulysses. It was decided that a multi-mission 
telemetry system would be implemented to do 
both jobs. The resultant system was the Data 
Staging and Capture System (DACS). While 
the DACS was not completely multi-mission, 
it has been estimated that about 70% of it is 
common between the two projects. The 
Voyager DACS provided data to their 
telemetry system and the Voyager DRS. The 
Ulysses DACS provides data to their Ulysses 
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Mission Control System (UMCS) and the 
Ulysses DRS. 

As the name implies, the BAGS provided disk 
for data staging. What the DACS also 
provides is a data request mechanism. This 
allows a Voyager Telemetry Operator, a 
UMCS analyst, or a DRS analyst to request 
data from one of seven files on disk. As an 
added value, since data was being loaded in 
real time, the requesting systems could ask 
for the file being loaded with real time data 
and ask for it to be given to them forever. 
While the controllers of the requesting 
systems could make data requests of the 
DACS, the end user, who is the one that really 
wants to look at the data, still has to make a 
request to the controllers. 

3. SPACEFLIGHT OPERATIONS CENTER 

While generations of telemetry systems 
marched by, technology marched forward. 
The concept of distributed processing has 
been used in many parts of the overall 
ground data system at JPL. These have been 
in very rigid configurations using point-to- 
point communication. What had not been 
done is to distribute that processing to the end 
user. Not until multi-tasking workstations 
that could communicate promiscuously with 
other workstations via a Local Area Network 
(LAN) were available that the end user could 
have their own processing to control. 

The concept of distributed processing, termed 
the Space Flight Operations Center (SFOC), 
communicating over a LAN with data staged 
and queried by members of the Spacecraft 
Team from a relational database was 
developed (Ref. 1,2). Several efforts sprung 
up in parallel. A Prototype Laboratory was 
set up to evaluate these new technologies in 
various combinations. System Engineering 
developed a System's Concept that utilized the 
technology that the Prototype Laboratory was 
to prove. 

3.1 The Prototype Laboratory 

With the need for new technology to be proven 
to answer the requirements of a telemetry 
system, the idea that the concept should be 
prototyped was developed. Rather than 


prototyping a specific concept, it was found 
that the Prototype Laboratory was prototyping 
prototyping. There was no specific answer 
that the Prototype Laboratory was looking for 
because there were so many options to be 
conceived and tried. However, there were 
three areas of concept that the Prototype 
Laboratory proved that were vital to the 
creation of SFOC. 

One of the early problems the Prototype 
Laboratory help solve was to find a relational 
database management system that could 
handle the data loading rates required and 
support binary data. Database management 
systems were primarily updated 
occasionally and the data queried many 
times. The concept in SFOC was that the 
engineering data was constantly being load 
along with many queries. Also, database 
management systems handled integers and 
floating point data but not binary data. The 
solution found by the Prototype Laboratory 
was Sybase. 

At this time many standards for LANs were 
evolving, Another concept proved by the 
Prototype Laboratory was Ethernet running 
TCP/IP. 

Finally, the Prototype Laboratory 
demonstrated that a workstation running 
Unix could meet the requirements of SFOC, 
allow the maximum number of vendors for 
competition, and not be faced with a solution 
that leads us to a dead end the future. 

3.2 Early SFOC 

Magellan was the first project supported by 
SFOC. It incorporated distributed processing 
based on workstations running Unix 
communicating a by LAN based on Ethernet 
and TCP/IP. The end users, i.e., the 
Spacecraft Team, could view real time 
engineering data on their workstations 
using Data Monitor and Display (DMD) 
displays they had created (Fig. 2,3). 

Additionally, thirty days of engineering 
data was kept online in a Sybase database 
management system that they could query. 
Queries of data eventually fell into two 
categories (Ref. 3). The first and most 


753 



frequent was the standard queries needed for 
morning report. These queries were 
incorporated into scripts that would run at 
night and have the reports produced 
automatically by the time the Spacecraft 
Team arrived in the morning. These scripts 
were eventually made to create a new script 
for the next nights query and schedule it to 
fire off. The other type of query, an ad hoc 
query, was when a problem or other 
interesting feature was found in the data and 
a query to look specifically at that data was 
created and submitted. 

3.3 Current SFOC 

Mars Observer and Voyager are currently 
supported by SFOC. Ulysses and Galileo will 
be supported by SFOC in the near future. 
These newer projects to SFOC use 
workstations based on the SPARC 
microprocessor. Magellan's workstations 
are based on the Motorola microprocessor 
and it did not seem prudent to port them to the 
new architecture. Thus the current SFOC is a 
second generation SFOC. Although no major 
changes in the original concept have 
occurred, a few lessons have learned and 
have been applied. 

A lesson learned from the Magellan 
experience is that only the most computer 
literate of the end users were comfortable 
with ad hoc queries. This second generation 
SFOC incorporated a new subsystem, the 
Telemetry Delivery Subsystem (TDS). TDS 
provides a single interface for acquiring 
data to the end user whether the data is 
resident in the database, stored in the TDS 
cache, or being broadcast over the LAN in 
realtime. 

Another lesson learned from Magellan was 
that the extra cost of color workstations could 
be justified for the end users. Instead of 
using reverse field in displays for flagging 
alarms (Fig. 1) red alarms could be 
displayed in red and yellow alarms 
displayed in yellow. Also windows could be 
color coded to enhance grouping of like data. 

4. FUTURE 

Major development of SFOC has ceased and 


has entered the sustaining mode. Knowing 
that there are still capabilities to add and 
enhancements to be made, SFOC has been 
renamed the Advanced Multimission 
Operations System (AMMOS) to indicate the 
need for these new initiatives to keep the 
system advanced. 

4.1 New Initiatives 

One way to use the DMD is to produce a file of 
processed data. Additional information is 
being added to this data to make it easier for 
end users to write their own programs in the 
analysis of spacecraft health with this data. 

One data type that is processed by AMMOS is 
termed status. The values that a status data 
type can take is the state of something, e.g., 
for a tape recorder off, on, record, etc. can be 
status values. Currently status values can 
only be displayed in tabular or text form. A 
Change Request has been submitted to be able 
to plot these values versus time. A user could 
then see, over a period of time, the states that 
some device or measurement has been- in 
(Fig. 4). 

A new initiative that has been proposed is for 
the DMD to accept the input of two data sources 
simultaneously and through some algorithm 
keep them synchronized with regards to 
time. In this way an analyst could forecast 
the behavior of a given channel and have the 
forecasted and real values displayed together 
to see if the spacecraft is following the 
predicted trend. 

Now that AMMOS has been around and used 
for awhile, the various operational teams and 
users are being surveyed to see how the 
system is used and how they would like to use 
it. Out of this effort new initiatives will be 
developed and funding will be request 
requested for their implementation. 

4.2 Cassini is Next 

The next approved flight project that will 
adapt AMMOS for its ground data system is 
Cassini which will visit Saturn. 

Cassini is planning for their analysts to 
have a display of the spacecraft and animate 
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it as things are happening. The analyst can 
rotate the image so that all aspects of the 
spacecraft can be viewed. Color can be used 
to indicate where measurements in alarm 
actually reside on the spacecraft or indicate 
temperature. 

The ability to acquire a set of interesting data 
is of little use if one is merely left with rows 
of numbers to peer at. Comprehension has 
been improved through the use of tailored 
displays for viewing individual 
measurements, the use of emerging 
visualization techniques such as 
spectrographs, and the use of an analyst's 
own software. The increased capability of 
visualizing data is, in large part, again due 
to the distribution of computing power to the 
end users. Innovative visualization of data 
continues to be of importance in the ongoing 
development of this evolving mission 
operations system and new technology is 
being introduced as it becomes available. 

5. REFERENCES 

1. Bahrami, K. A., et al. 1988. 
Automated Workstation for the Operations of 
Spacecraft Engineering Subsystems. In 
Information Systems Prototyping and 
Evaluation Quarterly Report No. 3, Flight 
Projects Office Information Systems 
Testbed, Jet Propulsion Laboratory, 
Pasadena, California. 


■:= •: :i »=i5 usr 59 > m 

=£7 Hi i= 49 8/1 CHI !/fl HSU RECFMI RIH 

:.crr iiE .*= rs9.9 s/i chi m ret m 

E2-9013 ??S/P ST t 080000 A0 20.09.32 
E2-80 19 .’FS/P ST l 900000A0 20.89.24 
£2-9065 F H'C STl 
E 2-0066 ?'K/C ST 2 
£2-0067 ?'Q'P5U 00000096 20.39 .27 
£2-9068 ?'0/PST2 900000F6 19.47.09 

£2-3133 m* EH8L ENABLE 19.47.14 
£2-314 1 PS1J18EHBL ENABLE 19.47.14 
£2-0099 li *; 

£2-9091 =VP9 1? *i 
£2-9092 
£2-9093 :*)«v 
£2-3132 : £ -"li 



E U E N 19.47.14 



88888828 

08088828 


Fig. 1 - DTY Display 
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Fig. 2 - DMD Fixed Display 
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Fig. 3 - DMD Channel vs. Time Plot 
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Fig. 4 - Status vs. Time Plot 
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